home *** CD-ROM | disk | FTP | other *** search
/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / gnu / objcissu.lha / class-hierarchy < prev    next >
Text File  |  1993-03-01  |  24KB  |  532 lines

  1. Date: Wed, 2 Sep 1992 11:14:27 -0700
  2. From: Mike Mahoney <mahoney@csulb.edu>
  3. To: gsk@marble.com
  4. Subject: Re: GNU Objective-C Project Has Begun
  5. Cc: glover@uh.edu
  6.  
  7. John Glover has some very nice examples of non-NeXTSTEP Objective-C
  8. programs for beginners in his UHOOP notes, at the sonata.cc.purdue.edu
  9. archive site.
  10.  
  11. - Mike Mahoney
  12.   SCaN President and SCaNeWS co-editor
  13.   Southern California NeXT Users' Group
  14.  
  15.   also ...
  16.   Professor and Chair
  17.   Computer Engineering and Computer Science Dept
  18.   California State University, Long Beach
  19.   Long Beach, CA  90840-8302
  20.  
  21. From: rpomeroy@aunext3.cam.amd.com (Ron Pomeroy x(Coop))
  22. Newsgroups: comp.lang.objective-c
  23. Subject: Re: Objective C library, Free Software Foundation
  24. Date: 2 Sep 92 15:00:44 GMT
  25.  
  26. For the last few months I've been using both Objective-C on the NeXT and  
  27. SmallTalk\ObjectWorks on various platforms.  My conclusions ?  NeXT smokes  
  28. everyone when it comes to the GUI classes, but is sorely lacking when it comes  
  29. to data modeling classes (i.e. Set, Bag, SequenceableCollection, Collection,  
  30. SortedCollection, OrderedCollection, Array, etc. etc. etc....the list is long)  
  31. like we find in SmallTalk.  What I would love to see is equivalents to these on  
  32. the Obj-C side.  FSF seems like the one to do the job :-)
  33. --
  34. Ronald Pomeroy
  35. Advanced Micro Devices
  36. CAM Applications Group
  37. rpomeroy@aunext3.amd.com
  38.  
  39. Newsgroups: comp.lang.objective-c
  40. From: ogeisser@uni-paderborn.de (Oliver Geisser)
  41. Subject: Re: Objective C library, Free Software Foundation
  42. Date: Fri, 4 Sep 1992 17:02:24 GMT
  43.  
  44. rpomeroy@aunext3.cam.amd.com (Ron Pomeroy x(Coop)) writes:
  45. : In article <1992Sep1.204045.42152@ns1.cc.lehigh.edu> gdb0@ns1.cc.lehigh.edu  
  46. : (GLENN BLANK) writes:
  47. : For the last few months I've been using both Objective-C on the NeXT and  
  48. : SmallTalk\ObjectWorks on various platforms.  My conclusions ?  NeXT smokes  
  49. : everyone when it comes to the GUI classes, but is sorely lacking when it comes  
  50. : to data modeling classes (i.e. Set, Bag, SequenceableCollection, Collection,  
  51. : SortedCollection, OrderedCollection, Array, etc. etc. etc....the list is long)  
  52. : like we find in SmallTalk.  What I would love to see is equivalents to these on  
  53. : the Obj-C side.  FSF seems like the one to do the job :-)
  54. : --
  55. : Ronald Pomeroy
  56. : Advanced Micro Devices
  57. : CAM Applications Group
  58. : rpomeroy@aunext3.amd.com
  59.  
  60.  
  61. I agree with you !!!!!
  62.  
  63. List class and storage class are well done, but that is not enough. Where are the other
  64. usefull classes, i.e. a B-Tree ?
  65.  
  66. Ciao !
  67.  
  68.         Olli
  69. -- 
  70. |  Oliver Geisser * Steindruefft 11 * W-4791 Altenbeken 3 * Germany  |
  71. |      e-mail: ogeisser@uni-paderborn.de * Phone: 05255/7966         |
  72. |     I prefer ASCII-Mail, but you can also send me NeXT-Mail        |
  73.  
  74. From: MKK2@psuvm.psu.edu
  75. Date:    Tue, 8 Sep 92 15:50 EDT
  76. Subject: Your mission, should you choose to accept it. . .
  77. To: gnu-objc@prep.ai.mit.edu
  78.  
  79. This group could do and could be a lot of different things.  It seems to me
  80. that some discussion of a "mission" are in order.  If we can agree on
  81. some long range goals, then we can try to form teams that will work on
  82. the first steps towards those goals.
  83.  
  84.    The long range goal still seems to be pretty general, like "Create lots
  85. of useful Obj-C Free software."  That's OK by me, at this point.
  86.  
  87.    As a first step in that direction, let me propose an immediate bojective:
  88. Create a set of classes that implement the usual data structures that is
  89. general, extensible, reusable, and similar to other similar sets.
  90.  
  91.    Since I am working in NeXTstep, one obvious bias I have is toward the
  92. already existing Object, Storage, List, and HashTable.  I'd like to see
  93. subclasses of these built along the lines of Smalltalk for Bags, Sets,
  94. Queues, etc etc etc.  Along the way, I hope that others would take on the
  95. task of making clones of the NeXTstep common classes, so that none NeXT
  96. programmers and NeXT programmers could write common code.
  97.  
  98. just a thought.
  99.  
  100. Date: Thu, 10 Sep 1992 15:12:40 -0700
  101. From: Bruce Nilo <bruce@ictv.com>
  102. To: gnu-objc@prep.ai.mit.edu
  103. Subject: Re: Your mission, should you choose to accept it. . .
  104.  
  105. [moved PROTOCOL IMPROVEMENT]
  106. [moved ERROR HANDLING]
  107. [moved BETTER RUNTIME SUPPORT FOR MULTI-THREADED PROGRAMS]
  108.  
  109. GENERAL DATA STRUCTURES:
  110.  
  111. NeXT provides a minimal set of data structures. They often do not
  112. handle conceivable errors, and do not specify protocols which they
  113. follow. (In addition they are often curiously named. For example List
  114. is not a traditional list. In more traditional circles it would be
  115. referred to as a dynamic array. Why not call it that?)
  116.  
  117. When building a container class library reasonable interfaces
  118. (protocols) should be defined, shared, and consistently used
  119. throughout. Errors should be reliably reported. (Perhaps class names
  120. could be based on implementation as opposed to interface?) Some useful
  121. data structures which come to mind include B-Trees, Red Black Trees,
  122. AVL trees, priority queues (or heaps) Lists, Stacks, and Queues. In
  123. general it would be nice to know the algorithms used to manage these
  124. data structures (or at least their worst case time/space complexity
  125. bounds.) The reason for this is that hiding behind any interface can
  126. be a >= N**2 implementation.
  127.  
  128. - Bruce D. Nilo
  129.  
  130. VP Software Systems
  131. ICTV
  132.  
  133. Date: Thu, 10 Sep 92 11:31:08 EDT
  134. From: dstrout@darpa.mil (David Strout)
  135. Received: by NeXT Mailer (1.82)
  136. To: gnu-objc@prep.ai.mit.edu
  137. Subject: What must we have, what can wait?
  138.  
  139. Well, I guess it's time to throw my 2 cents in....
  140.  
  141. My goal for the project is to see a baseline set of objects that behave identically between the GNU system and the NeXT system.  What I hope for is that a program written under GNU ObjC would compile & run under NeXT.  Going the other way (NeXT -> GNU) does not seem as necessary to me.  It may not be appropriate, or even desirable, for the GNU system to try and replicate every feature of NeXTStep.  We could lose alot of time trying implement Speaker / Listener while there was yet work to be done on Window, for example.
  142.  
  143. Suggestion 1:  Someone (or a small group) identify the minimum set of objects that GNU needs to support to do useful application development.  I believe that these objects should be chosen from what NeXT supplies.  NeXT's specs are easily available, clear, and designed to work together.  Choosing a few objects from NeXT, a few from Stepstone, a few from SmallTalk, etc. will multiply the time to completion by a large factor, due to the extra integration work required.
  144.  
  145. Suggestion 2:  Delay thoughts of an InterfaceBuilder-like program.  That can come after we have a basic appkit.  It's great to be able to drag a button off of a palette, but it's just as effective to say myButton=[[Button alloc] init] in a piece of code.
  146.  
  147. In essence, what I am saying is to avoid chrome for the moment and concentrate on that subset of features that are required to make an useful system.  There is alot of creativity in this group, alot of enthusiasm, and alot of skill.  I am simply advocating that we try to temper that with some discipline and restraint.  There will be a time for every idea, no doubt.  Its just that careful thought needs to go into the order in which the ideas are pursued.
  148.  
  149. dave.
  150. --
  151. Dave Strout
  152. dstrout@darpa.mil
  153. NeXTMail preferred
  154. 703/243-9467
  155. /* Any opinions expressed are strictly mine,
  156. *  Not ISI's, DARPA's, or the US Gov's.
  157. */
  158. Thompson's Rule for First Time Telescope Makers:
  159. It is faster to make a four-inch mirror then a six-inch mirror than to make a six-inch mirror.
  160.  
  161.  
  162. Date: Thu, 10 Sep 92 17:18:49 -0500
  163. From: jr@alpo.media.com (J.R. Jesson)
  164. To: gnu-objc@prep.ai.mit.edu
  165. Subject: Re: Organizing groups
  166.  
  167. MKK2@psuvm.psu.edu writes:
  168.  
  169. > here are some thoughts on organizing this effort, or, for that matter,
  170. > determining what this effort is going to be, in the first part.
  171. >
  172. > PROJECTS
  173. >
  174. > We have to reach agreement on what the initial projects will be.  For
  175. > example, I suggest these two:
  176. >
  177. > 1.  EXTEND NeXTstep COMMON CLASSES.  NeXT includes Object, List, Storage,
  178. > and HashTable.  NeXT programmers need "the rest".  Bag, Set, OrderedList,
  179. > Stack, Queue, Heap, etc etc etc
  180. >
  181.  
  182. I've found NeXT's foundation class definitions to be grossly
  183. anemic.  Why use NeXT as the sole model for cloning classes?
  184. Stepstone, the progenitor of Objective-C, has a good basic class
  185. set.  (gee - I wonder if anyone has asked them to contribute ICpak101
  186. to the effort? No - you first!)  Or maybe we could use a Smalltalk'ish
  187. set of basic classes.  The point is not to look too closely at NeXT -
  188. I'm much more of an objective-C fan than I am a NeXT fan (ok, so I
  189. have a NeXT on my desk - so what?).
  190.  
  191. jr
  192.  
  193.  
  194. From: MKK2@psuvm.psu.edu
  195. Date:    Fri, 11 Sep 92 10:38 EDT
  196. Subject: Re: general direction
  197. To: gnu-objc@prep.ai.mit.edu
  198.  
  199. I can appreciate the goals of the FSF, an organization for which I have
  200. loooong had the utmost respect and admiration.
  201.  
  202. Even so, I want to make one small pitch for an approach that might smack of
  203. being too dependent on NeXTstep.
  204.  
  205. All NeXTstep classes are descendents of Object.  Object provides some important
  206. services that many, if not all, NeXT programs avail themselves of.  For
  207. One example, Object is where some basic archiving and unarchiving capabilities
  208. reside, so that any class can be archived with a simple NXWriteObject() call.
  209. (Omitting all the details, of course.  You get the idea.)
  210.  
  211. So, for new classes like SortedList, PriorityQueue, and whatever to be fully
  212. useful to a NeXT programmer, they should also inherit from Object.  This
  213. does make them NeXTstep "dependent" in a sense, which is *bad*.  My hope is
  214. that we can create a GnuObject that is sufficiently compatible with NeXT's
  215. Object so that both NeXT and non-NeXT GNU OBJ-C programmers can use them
  216. in the same way, with perhaps a few #ifdef's making the whole thing
  217. transparent.
  218.  
  219. I don't know much about the Obj-C runtime.  Perhaps Object is actually OBJ-C
  220. standard, and not just NeXTstep?
  221.  
  222. Date: Fri, 11 Sep 92 09:03:57 CDT
  223. From: shirley@gothamcity.jsc.nasa.gov (Bill Shirley [CSC])
  224. To: gnu-objc@prep.ai.mit.edu
  225. Subject: design decisions
  226.  
  227. |> MKK2@psuvm.psu.edu writes:
  228. |> 
  229. |> > here are some thoughts on organizing this effort, or, for that  
  230. |> matter,
  231. |> > determining what this effort is going to be, in the first part.
  232. |> > 
  233. |> 
  234. |> > PROJECTS
  235. |> > 
  236. |> 
  237. |> > We have to reach agreement on what the initial projects will be. For
  238. |> > example, I suggest these two:
  239. |> > 
  240. |> 
  241. |> > 1.  EXTEND NeXTstep COMMON CLASSES.  NeXT includes Object, List, Storage
  242. |> > and HashTable.
  243.  
  244.         (NX)StringTable, (NX)StreamTable
  245.  
  246. |> > NeXT programmers need "the rest".  Bag, Set, OrderedList,
  247. |> > Stack, Queue, Heap, etc etc etc
  248. |> > 
  249. |> 
  250. |> 
  251. |> I've found NeXT's foundation class definitions to be grossly 
  252. |> anemic.  Why use NeXT as the sole model for cloning classes?
  253.  
  254. I agree that NeXT's Obj-C should not be the 'sole model' for paterning
  255. the Class Library after.  I do however think that it would be useful
  256. to provide some  NeXT(STEP) backwards compatibility because that is 
  257. where the current largest installed base of (possibly free) objects is.
  258.  
  259. I think a good way to do this would be to provide the BC ability in a
  260. category that can be included or not.
  261.  
  262. Someone else mentioned that NeXT's List Class is what you would normally
  263. think of as a List, it is actually a DynamicArray (and a DynamicArray
  264. of IDs at that).  So, I could see a DynamicArray object (which is kindof
  265. like NeXT's Storage).  With a List.[hm] and Storage.[hm] files that are
  266. actually categories of DynamicArray, allowing Source Code compatibility
  267. to some code someone has already written on the NeXT.
  268.  
  269. Of course, if the person who writes a Class (DynArray), doesn't know
  270. much/anything about the NeXT then s/he/it could leave it to someone else
  271. to implement.
  272.  
  273. I'm not first-hand-familiar with Stepstone, but the same thing could
  274. possibly be done for their interfaces as well.  
  275.  
  276. (I also think this way the Classes could be 'designed from scratch' and
  277.  if any legalities arose from providing BC interfaces to objects, they
  278.  could be yanked from the distribution and we would still have functional
  279.  objects.)
  280.  
  281. |> Stepstone, the progenitor of Objective-C, has a good basic class
  282. |> set.  (gee - I wonder if anyone has asked them to contribute ICpak101
  283. |> to the effort? No - you first!)  Or maybe we could use a Smalltalk'ish
  284.  
  285. No - you first.
  286.  
  287. |> set of basic classes.  The point is not to look too closely at NeXT - 
  288. |> 
  289. |> jr
  290.  
  291.  Bill S.
  292.  
  293. Date: Fri, 11 Sep 92 10:42:34 EDT
  294. From: dstrout@darpa.mil (David Strout)
  295. To: gnu-objc@prep.ai.mit.edu
  296. Subject: Re: design decisions
  297.  
  298.  
  299. MKK2@psuvm.psu.edu writes:
  300. >  1.  EXTEND NeXTstep COMMON CLASSES.  NeXT includes
  301. > Object, List, Storage, and HashTable.  NeXT programmers
  302. > need "the rest".  Bag, Set, OrderedList, Stack, Queue,
  303. > Heap, etc etc etc
  304. >
  305.  
  306. Well, I must disagree.  I seem to get by just fine without any of "the rest" of those classes.  I am not saying that they wouldn't be useful, just that they are not required for application development.  Seems to me that getting a very basic set of NeXTStep compatible objects running ought to take priority over extentions or additions.  I'm not claiming that NeXTStep is complete, or that it offers everything you could ever want.  But it is a complete and functional system.  Essentially, if something is not in NeXTStep, I feel we need to ask a couple of questions before we conclude that it's a "must have".
  307.  
  308. 1.) How did NeXT live without it?  
  309.  
  310. 2.) Is there a more general class that can be abused to do what we want or that provides 90% functionality?
  311.  
  312. I don't want to imply that classes other than what NeXT supplies are bad, I just want to suggest that maybe they should be delayed until the foundation is set is soild.
  313.  
  314. dave.
  315. --
  316. Dave Strout
  317. dstrout@darpa.mil
  318. NeXTMail preferred
  319. 703/243-9467
  320. /* Any opinions expressed are strictly mine,
  321. *  Not ISI's, DARPA's, or the US Gov's.
  322. */
  323. "If you have too many special cases, you're doing it wrong"
  324.  
  325. Date: Fri, 11 Sep 1992 12:55:55 EDT
  326. From: gdb0@lehigh.edu (GLENN BLANK)
  327. Subject: Automatic input/output, persistence
  328. To: gnu-objc@prep.ai.mit.edu
  329.  
  330. A key difference between the NeXT and StepStone foundation class
  331. libraries is the latter supports a much more convenient scheme
  332. for storing objects to and reading them back from files.
  333. The NeXT version, as I understand it (I don't have a NeXT; I have
  334. a Sun running Stepstone's version), only supports what I would call
  335. "semi-automatic" input/output--that is, the implementor of each subclass
  336. must implement methods to archive objects of this subclass.  The
  337. Stepstone library does not require any new implementation at all.  If
  338. your object is a subclass of Stepstone's Object, it automatically
  339. inherits Object's hooks automatic input/output--providing you
  340. explicitly link in the relevant code.  
  341.  
  342. Semi-automatic input/output is about all C++ libraries can do:
  343. since C++ does not support metaclass information at run-time.
  344. Automatic input/output is one of the very nice features of Smalltalk,
  345. which Objective-C can imitate, because it does support metaclasses,
  346. and so can know how to allocate instances of some class when it
  347. reads one from a file.  Needless to say, automatic input/output
  348. can save a lot of work, especially in continually evolving
  349. applications like mine.  I'd sure like to see support for it in the 
  350. GNU version, rather than settle for the NeXT interface.
  351.  
  352. May I point out that automatic input/output also opens the door
  353. for object persistence.  This need not imply a full blown OODB,
  354. with query capabilities, etc.  The StepStone implementation stores 
  355. one whole object per file--the object can be arbitrarily complex,
  356. e.g., the filer will handle vanilla C instance variables, 
  357. chase object ids, yet avoid duplicating objects to which there
  358. is more than one pointer.  A more flexible design might allow one 
  359. to store/access many objects per file.  
  360.  
  361.  
  362. Date: Fri, 11 Sep 1992 14:21:25 EDT
  363. From: gdb0@lehigh.edu (GLENN BLANK)
  364. Subject: re: automatic input/output, persistence
  365. To: gnu-objc@prep.ai.mit.edu
  366.  
  367. From: liberte@ncsa.uiuc.edu (Daniel LaLiberte)
  368.  
  369. >Does the automatic input/output let subclasses override the input/output
  370. >so that different info may be read/written?   This would provide the
  371. >best of both automatic and manual mechanisms.
  372.  
  373. Stepstone's reference manual says that you can substitute your own 
  374. Filer class, or have several alternatives, for the AsciiFiler class
  375. which provides their automatic I/O support.  Your alternative
  376. Filer class must then implement methods which responds to the 
  377. appropriate messages.  Note that this doesn't spread the
  378. implementation of I/O across all the client classes.
  379.  
  380. Another nice feature of AsciiFiler is that it allows you to
  381. show the contents of any object at run-time--very handy
  382. for debugging!  Does the NeXT version offer anything comparable?
  383.  
  384. >dan
  385.  
  386. glenn
  387.  
  388. Date: Tue, 15 Sep 92 09:14:27 -0400
  389. From: athan@object.com (Andrew C . Athan)
  390. To: uunet!stb.info.com!michael@uunet.uu.net (Michael Gersten)
  391. Subject: Re: Idea for class structure.
  392. Cc: gnu-objc@prep.ai.mit.edu
  393.  
  394.  
  395. > "fakeobject" classes cannot be used...
  396.  
  397. My first reaction to this is that it seems like an add-hoc solution .. a "hack" to get things working.  I think solving this is more of a design issue than anything else.  The problem can be solved in at least four ways without compiler support (see below).  Now, I'm not saying some of these ways aren't hacks themselves, but they have the advantage that they don't involve changing the compiler.  The least desirable method is (2).
  398.  
  399.     (1) design your container class better, so that -it- does not call new but instead gets passed an id in which it uses as is.
  400.     (2) Pass in an instance of a class that forwards all messages to some given object, except for "new" which returns the object itself.
  401.     (3) "UniqueString" instances should respond to everything the the class object of "UniqueString" does (perhaps simply by forwarding to their class).
  402.     (4) "UniqueString" class should responds to new/alloc/allocFromZone by returning "self" and should overide "free" to "do nothing." (which class objects do already, no?)
  403.  
  404.  
  405. Here's how you might use a "forwarding" class in the case where you cannot use solutions (1),(3) or (4) because you don't have the source code [FakeNewClass can be made much simpler if you know ahead of time the set of methods that might ever be called on it.  In fact, if you know it needs only "new" than all you need are the init and new methods implemented in Forwarder below]:
  406.  
  407. { ... lots of code
  408.     {
  409.       id forwarder;
  410.     [[someContainer alloc] initFromClass:
  411.      forwarder=
  412.            [[Forwarder alloc] initWithObject:[UniqueString class]];
  413.       [forwarder free]; //If you're sure it doesn't need it any more
  414.   ...
  415. }
  416.  
  417.  
  418. @interface Forwarder:Object
  419. {
  420.   id someObject;
  421. }
  422.  
  423. - initWithObject:obj;
  424. - setObject:obj;
  425. - new;
  426. - forward:(SEL)aSelector:(marg_list)marg;
  427. /* Also should implement all Object methods by forwarding to someClass */
  428. @end
  429.  
  430. @implementation FakeNewClass
  431.  
  432. - initWithObject:obj
  433. {
  434.   [super init];
  435.   [self setObject:obj];
  436.   return self;
  437. }
  438.  
  439. - setObject:obj
  440. {
  441.   someObject=obj;
  442.   return self;
  443. }
  444.  
  445. - new
  446. {
  447.   return someObject;
  448. }
  449.  
  450. - forward:(SEL)aSelector:(marg_list)marg
  451. {
  452.   if([someObject respondsTo:aSelector]){
  453.     return [someObject performv:aSelector:marg];
  454.   } else {
  455.     [self doesNotRespondTo:aSelector]; //or whatever;  I forget the method name
  456.   }
  457. }
  458.  
  459. /* Implement rest of Object methods so that they forward to someObject */
  460.  
  461. @end
  462.  
  463.  
  464. Enjoy!
  465. Andrew Athan
  466.  
  467. Date: Wed, 16 Sep 92 09:47 PDT
  468. From: michael@stb.info.com (Michael Gersten)
  469. To: ucla-cs!prep.ai.mit.edu!gnu-objc@cs.ucla.edu
  470. Subject: re: Idea for class structure.
  471.  
  472. Perhaps I didn't make it clear before. This is not an ad hoc proposal.
  473.  
  474. Right now a class is at best an object of class 'Object'. This implies that there is no behavior specific to a class object that is not also true of all other objects.
  475.  
  476. The way that new classes are added to the inheritance hierarchy is buried in the dynamic loading routines.
  477.  
  478. There is no way to implement meta-class messages, such as "return a list of all the selectors that class X resonds to", without sticking it into class Object and having to check the passed arguments.
  479.  
  480. Here's some more comments that I've sent to someone else. It might do a better job of explaining things:
  481.  
  482. Date: Tue, 15 Sep 92 11:30:18 PDT
  483. From: michael (To: ucla-cs!jupiter.fnbc.com!billb)
  484. To: ucla-cs!jupiter.fnbc.com!billb
  485. Subject: Clarification
  486.  
  487. Right now a class is an object of type 'Object'.
  488.  
  489. Why not make it an object of type 'Classes'?
  490.  
  491. The class 'Classes' is where class specific behavior would be placed. And, as 'Classes' is a class, it could have class methods as well.
  492.  
  493. Examples: You could re-arrange/add to the inheritence hierarchy at run time by sending an 'inherit' message to an object of type 'Classes'; this would be handled by a method implemented in 'Classes' as an object (not factory) method. A new class would be created by sending a 'new' message to 'Classes' (the +new method); this would return a generic new class.
  494.  
  495. At the same time, when you declare 'Foo' to be a class, you are saying that 'Foo' is an object of type 'Classes', and 'FooClass' is a corresponding object of type 'MetaClasses'. The difference between these two would be that one would describe the behavior of classes -- such as getting a list of methods that are implemented, etc., the other would be for 'abstract superclass' behavior of classes. Only difference I can think of right now is that 'MetaClasses' would define a -new method that returns the appropriate existing class object -- this would let you say '[Foo new]' to get a new foo object (which could be implemented as Object:+new), or '[FooClass new]' to get a copy of the object of type 'Classes' that corresponds to Foo (and would be the same as '[Foo self]') (this would be implemented as MetaClasses:-new), or you could ask for a new class structure that you would then modify to create a new class (which is currently hidden inside of the dynamic loading primitives) (and would be implemented by either Classes:+new or MetaClasses:+new).
  496.  
  497. Note that if you want to have dynamic code (such as smalltalk or lisp), you need a way to have dynamic hierarchies. After all, whats to stop someone from designing a system where you have an incremental compiler, and the compiler and debugger are part of the execution environment, and after you define a class it is now part of the compilation environment? (And there is little or no distinction between the compilation environment and the run time environment).
  498.  
  499.         Michael
  500.  
  501. --
  502.         Michael Gersten        michael@stb.info.com
  503. HELLO! I'm a signature virus! Join in the fun and copy me into yours!
  504. ex:.-1,. w $HOME/.signature
  505.  
  506. Date: Thu, 17 Sep 92 10:35:33 PDT
  507. From: excalib!blackbox!chuckb@ucsd.edu (Chuck Bernstein)
  508. To: gnu-objc@prep.ai.mit.edu
  509. Subject: Re: Automatic input/output, persistence
  510.  
  511. This is in reference to all of the discussion on the differences between object archiving on NeXT and Stepstone.  Why not just write an equivalent to Stepstone's default AsciiFiler class using @encode of the class to archive?  The resulting string could be processed, byte by bye, with default behaviours per data type.  This is probably what Stepstone is basically doing, anyway.
  512.  
  513. -chuck
  514.  
  515. From: MKK2@psuvm.psu.edu
  516. Date:    Thu, 1 Oct 92 16:50 EDT
  517. Subject: libg++ info wanted
  518. To: gnu-objc@prep.ai.mit.edu
  519.  
  520. I'd like to take a look at the classes in libg++.  At this point I need
  521. to know what the classes are, and what methods are implemented.  If
  522. I could find a discussion of design decisions, that would be great, too.
  523.  
  524. I know that the .tar.Z files are on prep.ai.mit.edu, but getting FTP'd
  525. files through this ebcdic mainframe and a 2400bps  pipeline is a real
  526. hassle, so I was wondering if someone could point me to a printed version
  527. of the docs, or offer to email me the man pages, or whatever.
  528.  
  529. thanks
  530.  
  531.  
  532.